Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-126

Text File | 1995-12-31 | 92.4 KB | 2,579 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 05 Dec 95       Volume 3 : Issue 126

Today's Topics:

        AOCE mailing list??
        Alternative Developer Tools
        Code Fragment To Identify Disk types
        Control Strip Modules
        Dave Marks and ints
        Drag and Drop ShowDragHilite problem
        Picture's Bounding Region?
        Plugins?  How?
        Programing For Joysticks?
        Registering File Creators and Types
        ResourceHandle?
        Text is text is text...isn't it?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Jonas Chemnitz)
Subject: AOCE mailing list??
Date: 17 Nov 1995 16:46:45 GMT
Organization: Uppsala University

Is there any AOCE mailing list??

/JC


+++++++++++++++++++++++++++

>From [e-mail] (Gavin Eadie)
Date: Mon, 20 Nov 1995 16:35:31 -0500
Organization: U of Michigan

In article <48ie9l$[e-mail]>, [e-mail] (Jonas
Chemnitz) wrote:

> Is there any AOCE mailing list??
>
> /JC

Yes, there is.  Send mail to [e-mail] with SUBJECT of HELP ... Gav
--
Gavin Eadie // U of Michigan.
            // Ramsay Consulting.

---------------------------

>From [e-mail] (Tim Lahey)
Subject: Alternative Developer Tools
Date: Sat, 11 Nov 1995 23:12:43 -0500
Organization: Bell-Northern Research

With all the talk these days about Codewarrior and Symantec, it has been
hard to find information about alternatives to these two. It will be important
for me to be able to build 68K OpenDoc parts and containers. Environments I have
been considering are:

QKS Smalltalk Agents
LS Object Pascal
MPW Pro (I'm used to UNIX/DOS programming)
Digitool Macintosh Common Lisp
Prograph CPX

Of secondary importance is the ability to use Quickdraw3D but since I will not
be developing immediately for PowerMac it is less important. Object Pascal
seems to be a better object-oriented environment than C++. MPW would
provide a familiar programming environment, and I don't like the feel of
the Metrowerks environment. MCL has steep fees for the redistribution kit,
and Prograph, well I never liked flowcharts to begin with.

Can anyone provide further information on the suitability of the above for
68K OpenDoc development and their programming environment ?

Thanks,

Tim Lahey

- -
I speak for myself, not BNR

+++++++++++++++++++++++++++

>From [e-mail] (Martin-Gilles Lavoie)
Date: Mon, 13 Nov 1995 08:11:47 -0500
Organization: ZERCOM Technologies Inc.

In article <stu6c71-1111952312430001@47.221.33.6>, [e-mail] wrote:

> With all the talk these days about Codewarrior and Symantec, it has been
> hard to find information about alternatives to these two. It will be important
> for me to be able to build 68K OpenDoc parts and containers.
Environments I have
> been considering are:
>
> QKS Smalltalk Agents
> LS Object Pascal
> MPW Pro (I'm used to UNIX/DOS programming)
> Digitool Macintosh Common Lisp
> Prograph CPX
>
> Of secondary importance is the ability to use Quickdraw3D but since I will not
> be developing immediately for PowerMac it is less important. Object Pascal
> seems to be a better object-oriented environment than C++. MPW would
> provide a familiar programming environment, and I don't like the feel of
> the Metrowerks environment. MCL has steep fees for the redistribution kit,
> and Prograph, well I never liked flowcharts to begin with.
>
> Can anyone provide further information on the suitability of the above for
> 68K OpenDoc development and their programming environment ?
>

I dont think there should be any reason for you to settle for either
Symantec or metrowerks if you're used to Unix-style programming.  MPW will
provide you with greater flexibility on the actual language and compiler
you can use, and the way you build your stuff (no restrictions
whatsoever).  The generated code is also superior in MPW than in anything
else yet.  At least, those are my results and those of other people,
including Apple Engineers.

As for those who argue that developping under Symantec and CodeWarrior is
faster, I'm encountering a list of tasks that would argue with those
claims.  Those compilers may be fast at compiling, but for a seasoned MPW
user, MPW can be made *very* fast with just a few simple things (MPW too
can use pre-compiled headers, and we can put our object code anywhere we
want--including a RAM Disk).

Martin-Gilles Lavoie
- -------------------------------------------------------------------
No!...try not.  Do, or do not.  There is no try.
    --Yoda on error handling.

Wars does not make one great.
    --Yoda on "Great Warrior"

+++++++++++++++++++++++++++

>From [e-mail] (Christopher R. Bailey)
Date: Mon, 13 Nov 1995 10:22:18 -0800
Organization: Beetle's Sprawl

In article <stu6c71-1111952312430001@47.221.33.6>, [e-mail] wrote:

> With all the talk these days about Codewarrior and Symantec, it has been
> hard to find information about alternatives to these two. It will be important
> for me to be able to build 68K OpenDoc parts and containers.
Environments I have
> been considering are:
>
> QKS Smalltalk Agents
> LS Object Pascal
> MPW Pro (I'm used to UNIX/DOS programming)
> Digitool Macintosh Common Lisp
> Prograph CPX
>
> Of secondary importance is the ability to use Quickdraw3D but since I will not
> be developing immediately for PowerMac it is less important. Object Pascal
> seems to be a better object-oriented environment than C++. MPW would
> provide a familiar programming environment, and I don't like the feel of
> the Metrowerks environment. MCL has steep fees for the redistribution kit,
> and Prograph, well I never liked flowcharts to begin with.
>
> Can anyone provide further information on the suitability of the above for
> 68K OpenDoc development and their programming environment ?

While not directly related to 68K OpenDoc dev, if you are looking at
alternatives, you might also want to check out ParcPlace VisualWorks.  The
advantage would be that it's cross platform, very "full featured", and I
believe they are looking into OpenDoc support.

The biggest problem you'll have is that OpenDoc, as of now, is fairly
entrenched in C++.  Check out comp.soft-sys.middleware.opendoc for more
information.  I'd be interested in what you decide on.

_____________ Christopher R. Bailey _____________
[e-mail]
http://www.quake.net/~baileyc
Macintosh, for those who can see through Windows.
Ride fast, take chances!

+++++++++++++++++++++++++++

>From [e-mail] (Ari Halberstadt)
Date: Mon, 13 Nov 1995 19:36:33 -0400
Organization: North Shore Access/Eco Software, Inc; ([e-mail])

In article <mouser-1311950811470001@204.191.6.123>, [e-mail]
(Martin-Gilles Lavoie) wrote:

>In article <stu6c71-1111952312430001@47.221.33.6>, [e-mail] wrote:
>
>> With all the talk these days about Codewarrior and Symantec, it has been
>> hard to find information about alternatives to these two. It will be
important
>> for me to be able to build 68K OpenDoc parts and containers.
>Environments I have
>> been considering are:
>>
>> QKS Smalltalk Agents

Request a demo CD from them. You will get a lot of very useful
information, they are certainly very responsive in this respect (I
requested info by email on a Friday and had it on Monday!). I looked at
the demo and spoke with them at MacWorld. They have a lot of nice ideas,
but have not implemented many of them yet. For instance, they didn't have
a good GUI builder tool, and OpenDoc support and a native-PowerMac version
were not yet available when I spoke with them. There is also an issue of
using a non-standard environment (they make many extensions to SmallTalk).
It may also buy you cross-platform portability. I think that if they were
to add some major features, it would be a good environment for rapid
development of specific projects when you really don't want to have to
bother with C++.

Note: my information is several months old.

>> Of secondary importance is the ability to use Quickdraw3D but since I
will not
>> be developing immediately for PowerMac it is less important. Object Pascal
>> seems to be a better object-oriented environment than C++. MPW would
>> provide a familiar programming environment, and I don't like the feel of
>> the Metrowerks environment. MCL has steep fees for the redistribution kit,
>> and Prograph, well I never liked flowcharts to begin with.
>>
>> Can anyone provide further information on the suitability of the above for
>> 68K OpenDoc development and their programming environment ?

You should really consider upgrading to a PowerMac. With CW on a 7100/80,
I get 200K+ lines/minute for C code. This is several times faster than a
68K computer could provide. The new PowerMac's are really nice too, a lot
cheaper than what I paid just 8 months ago. It is incredible how much time
one can save when the compiler is faster.

The nicest things about CW and THINK are their source-level debuggers and
project files. The project files relieve the tedium of make files, but are
a bit hard to get used to coming from a Unix background, as well as being
more limiting (at least in CW, I haven't used Symantec C++ v8) than Make
files. Also, CW make building native-PPC apps easier.

The CodeWarrior CFM68K support does not work yet. I was unable to build a
CFM68K application or fragment, while identical code worked for PowerPC.
Metrowerks is working on the problem. For now, MPW is probably your only
bet for 68K OpenDoc development.

The old MPW C compiler is really not so hot. For optimized C++ code, you
might want to look at the Motorola compilers. If you get CodeWarrior, you
also get MPW and can use the CW compilers from within MPW, which are a lot
faster than the regular MPW C. Symantec also offers MPW-hosted compilers
which are even distributed with Apple's ETO CD.

>I dont think there should be any reason for you to settle for either
>Symantec or metrowerks if you're used to Unix-style programming.  MPW will
>provide you with greater flexibility on the actual language and compiler
>you can use, and the way you build your stuff (no restrictions
>whatsoever).  The generated code is also superior in MPW than in anything
>else yet.  At least, those are my results and those of other people,
>including Apple Engineers.

I agree that MPW offers the greatest flexibility. If you need Make files
(you will need them for large projects) and good scriptability, MPW is a
must. The quality of generated code, however, really depends on the
compiler you plug in to MPW:

Newsgroups: comp.sys.mac.programmer.misc,comp.sys.mac.programmer.help
From: [e-mail] (Tom Dowdy)
Subject: Re: What does Apple use to develop MacOS?
Sender: [e-mail]
Date: Wed, 8 Nov 1995 20:45:19 GMT
Organization: Apple Computer, Inc.

>As for development environments and compilers, while many
>folks here use Metrowerks projects for daily work and quick
>turnaround, release versions of code are compiled with either
>the 'xlc' compiler on RS/6000s, or with MrC for MPW.  Both of
>these compilers have pretty darn good code optimizers, and it's
>worth the hassle of using them for shipping software.

I think it is worth owning MPW, CodeWarrior, and Symantec. For instance,
having THINK C 7 is very handy (even if I do my current programming with
CW) since I can easily use a lot of public code. Having MPW (via
CodeWarrior) is also very handy, since I can do a lot of scripting with
MPW that would be hard to do otherwise. I also am considering upgrading to
the latest Symantec product when it is released next year, as well as
maintaining my CodeWarrior subscription.

For commercial development, you should have at least one good C/C++
compiler environment. QKS SmallTalk has the potential to drop a lot of
time from the development of some projects by eliminating much of the
tedium and low-level hackery involved with C++. If QKS SmallTalk provides
some of the features I am waiting for, I think it may be the best non-C++
environment for Mac programming (unless something better comes along).

-- Ari Halberstadt ([e-mail], [e-mail])
<http://www.shore.net/~ari/> (under construction)
<ftp://ftp.shore.net/members/ari> (use this to get my latest software)

+++++++++++++++++++++++++++

>From Bob Brown <[e-mail]>
Date: 20 Nov 1995 07:53:32 GMT
Organization: DSTC PTY LTD

I am a BIG fan of Oberon.

There are several implementations available for MANY platforms.

Oberon/F is quite notable for its support of compound documents and its planned
migration to Opendoc/OLE.

See Guy Laden's list of Oberon related pkg's

http://www.math.tau.ac.il/~laden/Ob-pkgs.html

--
- -------------------------------------------------------------
BOB BROWN                      | Here I am, 'Living The Dream.'
DSTC PTY LTD                   |
Level 7, Gehrmann Laboratories | Trouble is, I don't know WHOSE
The University of Queensland   | dream and what induced it!
Q 4072                         |
Australia                      |
Tel: [phone]          |
FAX: [phone]         |
[e-mail]                |


---------------------------

>From [e-mail] (Donald L. Gover)
Subject: Code Fragment To Identify Disk types
Date: 20 Nov 1995 16:01:09 GMT
Organization: New Era Systems Services

  I'm looking for a code fragment that will allow me to determine
what kind of hardware each of the volumes on my MAC are. ie are they
CD, HardDrive, floppy or network? Anyone got such a thing?


   Thanks Don....

+++++++++++++++++++++++++++

>From [e-mail] (Marshall Clow)
Date: Mon, 20 Nov 1995 19:57:35 -0800
Organization: Aladdin Systems

In article <48q8o5$[e-mail]>, [e-mail]
(Donald L. Gover) wrote:

>  I'm looking for a code fragment that will allow me to determine
>what kind of hardware each of the volumes on my MAC are. ie are they
>CD, HardDrive, floppy or network? Anyone got such a thing?
>
>
Nope. :-(

Telling if a drive is local or remote is easy; call PBHGetVolParms and
check to see if buffer.vMServerAdr != 0.

Telling if a drive is a floppy is trickier. If all you care about is Apple
floppy drives, check to see if the driver name is '.Sony'. Of course, this
will also find old non-SCSI HD20 hard drives, but almost no one uses those
anymore.
For non-Apple floppy drives, it's harder. Check for small, ejectable
volumes, but watch out for ZIP drives, MO drives, etc, and watch out for
partitions on other media.

CD's are like floppies. Look for the driver name '.AppleCD'. For non-Apple
drives, again, you have to fall back on heuristics. Large, read-only,
ejectable media is probably a CD, but it may be a write-protected MO.

What, exactly, are you trying to accomplish?

-- Marshall

--
Marshall Clow
Aladdin Systems

"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety." -- Benjamin Franklin
 _Historical Review of Pennsylvania_, 1759

---------------------------

>From [e-mail] (Dave the Rave)
Subject: Control Strip Modules
Date: Mon, 20 Nov 1995 10:31:00 GMT
Organization: Unseen University, Ankh-Morpork

I've just started playing around with Control Strip Modules. I found
the Tech Note (OS06 I think) on the develop Bookmark CD and very
useful it was too. The only problem I had was that although the utility
routines were documented in their C form, there was no low level interface
information other than that the selector-based trap was 0xAAF2. After
some trial and error and MacsBugging around I deduced that the selector
for the pop-up menu was 0x0408, and that for the get-and-detach-an-icon-
suite call was 0x0506 (or was it 0x0507?) but of course there is no
systematic way to find out the selectors for the others so I can create
my own little interface file along the lines of

pascal SBControlStripUtilityRoutine(short param1,long param2,const Rect *param3)
        THREEWORDINLINE{0x303C,0x????,0xAAF2};

An update to the Tech notes perhaps, if any Apple people are reading this.
Or is there a (free) SDK I can get hold of?


Email me please...


______________________________________________________
@-|~ (Scientist formerly known as David A. G. Gillies)
                      (email: [e-mail])
You are in a maze of kinky little fetishes,  all alike
(c) 1995 Wittgenstein's Amazing Underwater Supermarket
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/


+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 21 Nov 1995 13:12:52 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Dave the Rave <[e-mail]> wrote:

>systematic way to find out the selectors for the others so I can create
>my own little interface file along the lines of
>
>pascal SBControlStripUtilityRoutine(short param1,long param2,const Rect *param3)
>       THREEWORDINLINE{0x303C,0x????,0xAAF2};

You should look for the file called <ControlStrip.h>. It's now part of
the Universal Headers. I don't know whether it is on the Bookmark CD,
but it comes with CW7.

>Or is there a (free) SDK I can get hold of?

I suggest you try the recently released Extensions Strip 1.1
Developer's Kit. Extensions Strip is a shareware equivalent to
Control Strip written by Ammon Skidmore. It more friendly to
programmers and it comes with example code. It should be on
Info-Mac in the cfg directory.

--
Francois
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (Brian Bechtel)
Date: 21 Nov 1995 17:34:23 GMT
Organization: Apple Computer, Inc.

>An update to the Tech notes perhaps, if any Apple people are reading this.
>Or is there a (free) SDK I can get hold of?

I didn't include the information found in ControlStrip.h because the
universal interfaces were changing.  Look at ControlStrip.h in the current
universal interfaces, available at
 <ftp://ftp.info.apple.com//Apple.Support.Area/Developer_Services/
  Tool_Chest/Interfaces/Universal_Interfaces.sit.hqx>

--
--Brian Bechtel    [e-mail]    "My opinion, not Apple's"
  Village Idiot, DTS

---------------------------

>From Shyguy <[e-mail]>
Subject: Dave Marks and ints
Date: Mon, 13 Nov 1995 10:06:42 -0800
Organization: California State University, Chico

He seems to have a aversion to ints.  In his book on macintosh c++
programing he says TWICE not to use ints.  Mind you this is 'int', not
'long int' or 'short int'

Yet I have never seen any other book say not to use ints!
Why the big fuss about using shorts or longs?  You can just tell the
compiler to treat ints as 2 bytes or 4 bytes anyways

+++++++++++++++++++++++++++

>From [e-mail] (Eric Hunt)
Date: Mon, 13 Nov 1995 12:53:11 -0600
Organization: metrowerks Corp.

In article
<[e-mail]>,
Shyguy <[e-mail]> wrote:

> Why the big fuss about using shorts or longs?  You can just tell the
> compiler to treat ints as 2 bytes or 4 bytes anyways

Portable code cannot ever depend on the size of an int. Shorts and longs
are known to be constant across platforms. If you get in the habit now of
never trusting an int, then you won't get burned in the future.

Eric Hunt
Metrowerks Technical Support

+++++++++++++++++++++++++++

>From [e-mail] (Peter S. Lau)
Date: 13 Nov 1995 19:28:35 GMT
Organization: Internex Online, Toronto, Ontario, Canada (416 363 3783)

In article <[e-mail]> Shyguy <[e-mail]> writes:

>He seems to have a aversion to ints.  In his book on macintosh c++
>programing he says TWICE not to use ints.  Mind you this is 'int', not
>'long int' or 'short int'
>
>Yet I have never seen any other book say not to use ints!
>Why the big fuss about using shorts or longs?  You can just tell the
>compiler to treat ints as 2 bytes or 4 bytes anyways

I haven't read the book but I know short is always 2 bytes, where int
could be 2 bytes (default in CW, at least for my copy) or 4 bytes (by
changing the preferences, and long is always 4 bytes (still right?).
I think I would appreciate the always rather than checking/setting the
preference.

Also, most Toolbox calls don't use int's, and I think it's a good
practice to match the types as much as possible.

My $0.02.

pete

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Mon, 13 Nov 1995 16:02:00 -0500
Organization: Carnegie Mellon, Pittsburgh, PA

Shyguy <[e-mail]> writes:
> He seems to have a aversion to ints.  In his book on macintosh c++
> programing he says TWICE not to use ints.  Mind you this is 'int', not
> 'long int' or 'short int'

And he's right.

> Why the big fuss about using shorts or longs?  You can just tell the
> compiler to treat ints as 2 bytes or 4 bytes anyways

That's exactly the reason. You *can* tell the compiler -- which means
you can also forget, or get it wrong.

It's not that rare that I've had to trash a compiler project file and
start over -- either the project file got corrupted, or I was changing
to a different compiler, or making a PPC project from what had been
a 68K project. At least twice in the past six months I've lost the
setting of int size -- leading to bugs that were, in both cases, hard
to track down. And that's when I was *trying* to avoid using ints.
They keep sneaking in.

I've ported Unix-box code to the Mac, too, and the same problem
arises.

To be honest, the int habit has been hard enough to break that I've
taken to putting
    if (sizeof(int) != 4) ExitToShell();
in my initialization code.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Jim Jarrett)
Date: Mon, 13 Nov 1995 15:31:06 -0500
Organization: Eastman Kodak Co. CD Imaging

In article
<[e-mail]>,
Shyguy <[e-mail]> wrote:

>
> Yet I have never seen any other book say not to use ints!
> Why the big fuss about using shorts or longs?  You can just tell the
> compiler to treat ints as 2 bytes or 4 bytes anyways

And this is EXACTLY why not to use ints. C does not put any definition on
what sizeof(int) should be.  If you try to port code across platforms (or
even across projects), you can have things break in all kinds of
fun-to-debug ways because compiler A had ints as 2 bytes and compiler B
has ints as 4 bytes.

short and long ARE defined, however.

+------------------------------------------------------------------------+
| Jim Jarrett, CCP                                                       |
| Eastman Kodak CD Imaging                                               |
| 901 Elmgrove Road MC 35400                                             |
| Rochester, NY 14653-5400 [phone]                                |
| [e-mail]          All opinions expressed are mine alone |
+------------------------------------------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (Leeuw van der TN)
Date: Mon, 13 Nov 1995 21:09:40 GMT
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam

Eric Hunt ([e-mail]) wrote:
: In article
: <[e-mail]>,
: Shyguy <[e-mail]> wrote:

: > Why the big fuss about using shorts or longs?  You can just tell the
: > compiler to treat ints as 2 bytes or 4 bytes anyways

: Portable code cannot ever depend on the size of an int. Shorts and longs
: are known to be constant across platforms. If you get in the habit now of
: never trusting an int, then you won't get burned in the future.

: Eric Hunt
: Metrowerks Technical Support


And I keep telling that to my friends and they just don't believe it's a
problem :-) Though luck for them.

--Tim
--
Tim van der Leeuw, student of Computer Science, Vrije Universiteit,
Amsterdam, The Netherlands. Homepage: http://www.cs.vu.nl/~tnleeuw/
Flightsim-Homepages!           http://www.cs.vu.nl/~tnleeuw/hornet/
                                  http://www.cs.vu.nl/~tnleeuw/A10/

+++++++++++++++++++++++++++

>From [e-mail] (Adam Winer)
Date: Mon, 13 Nov 1995 14:58:35 -0800
Organization: Oracle Corporation

In article <[e-mail]>,
[e-mail] (Jim Jarrett) wrote:

> In article
> <[e-mail]>,
> Shyguy <[e-mail]> wrote:
>
> >
> > Yet I have never seen any other book say not to use ints!
> > Why the big fuss about using shorts or longs?  You can just tell the
> > compiler to treat ints as 2 bytes or 4 bytes anyways
>
> And this is EXACTLY why not to use ints. C does not put any definition on
> what sizeof(int) should be.  If you try to port code across platforms (or
> even across projects), you can have things break in all kinds of
> fun-to-debug ways because compiler A had ints as 2 bytes and compiler B
> has ints as 4 bytes.
>
> short and long ARE defined, however.

Actually, they aren't, at least not by the ANSI committee.  They
do guarantee that: sizeof(short) <= sizeof(int) <= sizeof(long)

If you want to write truly portable code, and you care about
the size of your data types, define types like Apple does:
SInt4, UInt4, etc., and redefine these appropriately on all
platforms you port to.  On the Mac, long is always 4 bytes,
and short is always 2 (so far), but this definitely isn't
true in the world at large.

-- Adam Winer
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ari Halberstadt)
Date: Mon, 13 Nov 1995 19:03:39 -0400
Organization: North Shore Access/Eco Software, Inc; ([e-mail])

In article <[e-mail]>, [e-mail]
(Eric Hunt) wrote:

>In article
><[e-mail]>,
>Shyguy <[e-mail]> wrote:
>
>> Why the big fuss about using shorts or longs?  You can just tell the
>> compiler to treat ints as 2 bytes or 4 bytes anyways
>
>Portable code cannot ever depend on the size of an int. Shorts and longs
>are known to be constant across platforms. If you get in the habit now of
>never trusting an int, then you won't get burned in the future.

Portable code can depend only on the constraints defined by the ANSI
standard and by specific implementations in <limits.h> and <float.h>. The
sizes of shorts and longs are not constant across platforms. The standard
only requires that type int hold the values -32767..32767, which is a lot
less than what one often wants.

All current Mac compilers understand the concept of 2-byte shorts and
4-byte longs. A lot of fuss is avoided on the mac if you use a short int
where the Mac Toolbox expects a 2-byte signed integral value and a long
int where the Mac Toolbox expects a 4-byte signed integral value. You wont
get bitten by having to fiddle with compiler options or weird libraries
when going between MPW, THINK C, Symantec C++, CodeWarrior, etc. There are
some nasty bugs caused by these things; see Horwich, Josh "Kon & Bal's
Puzzle Page: Printing Pains", Develop 21, March 1995, p117-121.

It is worth noting that a lot of programmers (myself included) assumed (or
assume) that, on the mac, short is somehow magically tied to 2-byte values
and long is magically tied to 4-byte values. This is as incorrect as any
of the old assumptions of Unix programmers that int was 4-bytes and
therefore equivalent to a pointer, which has caused nearly endless wasted
hours. It is much more correct  and safer to use typedef's, such as those
finally added by Apple to the Universal Headers, which now include types
like

typedef short SInt16;

-- Ari Halberstadt ([e-mail], [e-mail])
<http://www.shore.net/~ari/> (under construction)
<ftp://ftp.shore.net/members/ari> (use this to get my latest software)

+++++++++++++++++++++++++++

>From [e-mail] (Roger Smith)
Date: Tue, 14 Nov 1995 02:47:52 -0500
Organization: Gold Disk

Try this one for size:

I get a crucial library from a third party developer that's supplied as a
code resource. The interfaces have shorts in the function prototypes. It
turns out the developer used think C (I use CW) for their development.
Because I set my 68K  project for 4 byte ints to maintain compatability
with the power pc version of my app (Not that I have int declarations in
my source, but I have an MPW background where ints are always 4 bytes), I
ran into bus errors calling functions in the 3rd party library . They were
trying to pop the wrong type from  the stack, strangely enough this bug
didn't always crash the machine.I ended up sending them a macsbug log, and
telling them how to fix the problem, but the bug persisted for a few weeks
as it was beyond my [source] control..

CW adds a different twist as you can mix the wrong ansi library and
compiler setting.

> To be honest, the int habit has been hard enough to break that I've
> taken to putting
>     if (sizeof(int) != 4) ExitToShell();
> in my initialization code.


Roger Smith...
Gold Disk Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Richard Wells )
Date: 14 Nov 1995 19:46:50 GMT
Organization: 3M Company

[e-mail] (Jim Jarrett) wrote:
>short and long ARE defined, however.

WARNING: Pedantry ahead!!!

They are only defined (by the ANSI standard) in the sense that
the following is required:

sizeof(short) <= sizeof(int) <= sizeof(long)

Also, shorts and ints must handle at least the range -32767..32767,
and longs must handle at least the range -2147483647..2147483647.

Of course, any Mac compiler that didn't have 16-bit shorts and
32-bit longs wouldn't last very long on the market.  But if your
code must be portable to other systems, and you really need to
use integers of given sizes (for use in binary files, for
instance), then I would suggest typedef'ing such types as int16,
int32, uint16, uint32, etc., in some header file that you know
may have to change for each system you port to.



+++++++++++++++++++++++++++

>From [e-mail] (Chris Page)
Date: Tue, 14 Nov 1995 14:26:52 -0800
Organization: Claris Corporation

In article <[e-mail]>, [e-mail] (Peter S.
Lau) wrote:

> I haven't read the book but I know short is always 2 bytes, where int
> could be 2 bytes (default in CW, at least for my copy) or 4 bytes (by
> changing the preferences, and long is always 4 bytes (still right?).
> I think I would appreciate the always rather than checking/setting the
> preference.

Though we should remember that no C types have standard sizes. On 64-bit
processors, some compilers make int 64-bits wide. When you think
"cross-platform", you're really only saying "Metrowerks C, Symantec C, and
MPW". The hard fact of life is that you cannot depend on the size of any
base C types and that if you have dependencies you should put some kind of
checking code or preprocessor conditions into your source to warn you if a
dependency is broken.

Of course, for practical purposes, if you're only programming for the Mac,
you can assume short ints are 16-bit and long ints are 32-bit (hmmm...what
happens when you start compiling for PowerPC 620's?).

--
Chris Page                      | Internet junk mail, advertisements,
Claris Corporation              | and SPAMs are inconsiderate...
[e-mail] |            Cut it out! :-P

Disclaimer: opinions are not necessarily those of my employer

+++++++++++++++++++++++++++

>From [e-mail] (Kevin Tieskoetter)
Date: 14 Nov 1995 20:07:33 GMT
Organization: Albatross Productions

In article <48arna$[e-mail]>
[e-mail] (Richard Wells ) writes:

> Of course, any Mac compiler that didn't have 16-bit shorts and
> 32-bit longs wouldn't last very long on the market.  But if your

Well, MPW has been around for a long time.....


-kevin

//---------------------------------------------------------------------
   Kevin Tieskoetter / Software Prestidigitator, Specular International
//---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Conor MacNeill)
Date: Thu, 16 Nov 1995 01:06:43 +1100
Organization: Cognet Pty Limited

In article <[e-mail]>, [e-mail]
(Eric Hunt) wrote:

> In article
> <[e-mail]>,
> Shyguy <[e-mail]> wrote:
>
> > Why the big fuss about using shorts or longs?  You can just tell the
> > compiler to treat ints as 2 bytes or 4 bytes anyways
>
> Portable code cannot ever depend on the size of an int. Shorts and longs
> are known to be constant across platforms. If you get in the habit now of
> never trusting an int, then you won't get burned in the future.

Well "never trusting" doesn't mean "not using". Where ever you plan to use
a short,
you can safely use an int since an int is always at least as big as a short.

One rationale I have heard put forward is that an int may be more
efficient than a
short on architectures with a 32 bit word size since shorts may require
extra masking
and sign extension operations.

>
> Eric Hunt
> Metrowerks Technical Support

--
- -
Conor MacNeill
[e-mail]
Cognet Pty Limited

+++++++++++++++++++++++++++

>From [e-mail] (Richard Wells )
Date: 15 Nov 1995 17:48:15 GMT
Organization: 3M Company

[e-mail] (Kevin Tieskoetter) wrote:
>In article <48arna$[e-mail]>
>[e-mail] (Richard Wells ) writes:
>
>> Of course, any Mac compiler that didn't have 16-bit shorts and
>> 32-bit longs wouldn't last very long on the market.  But if your
>
>Well, MPW has been around for a long time.....

And it uses 16-bit shorts and 32-bit longs.  What's your point?



+++++++++++++++++++++++++++

>From [e-mail] (Martin-Gilles Lavoie)
Date: Wed, 15 Nov 1995 14:11:37 -0500
Organization: ZERCOM Technologies Inc.

In article <[e-mail]>, [e-mail] (Leeuw van der TN)
wrote:

> Eric Hunt ([e-mail]) wrote:
> : In article
> : <[e-mail]>,
> : Shyguy <[e-mail]> wrote:
>
> : > Why the big fuss about using shorts or longs?  You can just tell the
> : > compiler to treat ints as 2 bytes or 4 bytes anyways
>
> : Portable code cannot ever depend on the size of an int. Shorts and longs
> : are known to be constant across platforms. If you get in the habit now of
> : never trusting an int, then you won't get burned in the future.
>
> : Eric Hunt
> : Metrowerks Technical Support
>
>
> And I keep telling that to my friends and they just don't believe it's a
> problem :-) Though luck for them.
>

There will come a time when longs will be considered a small data type.
Such as when we get to 128bit processors.  How will we name 128-bit data
types?
big longs?  I can see this from here:

        unsigned big long myFileSize    =   0BL;

And the 256-bits model:

        unsigned big long long myEventBiggerFileSize =   0BLL;

*Sigh*  Whish I've been forced to use UInt8-like types before.

Martin-Gilles Lavoie

And I'm being very serious at that.  Not.

+++++++++++++++++++++++++++

>From [e-mail] (kellyj)
Date: 15 Nov 1995 21:06:22 GMT
Organization: PL/LIDD

In article <mouser-1511951411380001@204.191.6.123>
[e-mail] (Martin-Gilles Lavoie) writes:

> There will come a time when longs will be considered a small data type.
> Such as when we get to 128bit processors.  How will we name 128-bit data
> types?

We'll just switch over to a Newspeak nomenclature:

unsigned double plus plus long x = 0DPPL;

This will allow for certain flexibility such as declaring nybble
(4-bit) sized shorts as well:

double plus short x = 0DPS;

this could be alternatively written:

double plus plus un-long x = 0DPPUL;

The intent is to eliminate int from our vocabulary, thereby preventing
the human soul from writing Quality Software (I heard that Bill Gates
is pioneering the Newspeak C++ [C double plus] standard ... go figure!)

Naturally the use of the keyword "double" presents a certain ambiguity,
especially when referring to extended precision floating point numbers:

double plus plus double y = 0.0;

You can also declare a double as a long or short double:

long double plus short double pi = 3.145;

This is left as a challenge to compiler designers and feisty
programmers everywhere. Of course with such control over the elemental
types, the need for arrays and structs is eliminated. To keep things
manageable, they're also introducing the car and cdr operators borrowed
from LISP to make reading source code easier.


--joe
[e-mail]
No, I'm deadly serious, so don't flame me!

+++++++++++++++++++++++++++

>From [e-mail] (Malcolm Slaney)
Date: Wed, 15 Nov 1995 07:28:30 -0800
Organization: Interval Research, Inc.

In article <[e-mail]>, [e-mail]
(Eric Hunt) wrote:
> Portable code cannot ever depend on the size of an int. Shorts and longs
> are known to be constant across platforms.

No true.... shorts are 48 bits long on a Cray (stored in 64 bits of
memory) and longs are 64 bits long.  There is going to be more pressure
for longer ints as microprocessors move to 64 bit words.

The only guarantee about word size is that
   sizeof(short) <= sizeof(int) <= sizeof(long)

-- Malcolm

+++++++++++++++++++++++++++

>From [e-mail] (Harold Ekstrom)
Date: Wed, 15 Nov 1995 10:56:44 -0800
Organization: the ag group, inc.

In article <[e-mail]>, [e-mail] (Ari
Halberstadt) wrote:

> [...]
>It is much more correct  and safer to use typedef's, such as those
>finally added by Apple to the Universal Headers, which now include types
>like
>
>typedef short SInt16;

On another note, it'd be nice to also have to these "fixed size" types
defined for floating point types. We've already got float_t and double_t
defined for efficiency. How about Float32 and Double64?

-Harold

- ------------------------------------------------------------
Harold Ekstrom
the ag group, inc.
<ftp://ftp.aggroup.com/>
<http://www.aggroup.com/>

+++++++++++++++++++++++++++

>From [e-mail] (Kevin Tieskoetter)
Date: 15 Nov 1995 20:40:14 GMT
Organization: Albatross Productions

In article <48d94v$[e-mail]>
[e-mail] (Richard Wells ) writes:

> >> Of course, any Mac compiler that didn't have 16-bit shorts and
> >> 32-bit longs wouldn't last very long on the market.  But if your
> >
> >Well, MPW has been around for a long time.....
>
> And it uses 16-bit shorts and 32-bit longs.  What's your point?

Oops..I misread that...I thought it was saying "16-bit ints"...so much
for posting without reading thoroughly... :-)


-kevin

//---------------------------------------------------------------------
   Kevin Tieskoetter / Software Prestidigitator, Specular International
//---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Kevin Tieskoetter)
Date: 15 Nov 1995 20:41:41 GMT
Organization: Albatross Productions

In article <[e-mail]>
[e-mail] (Malcolm Slaney) writes:

> No true.... shorts are 48 bits long on a Cray (stored in 64 bits of
> memory) and longs are 64 bits long.  There is going to be more pressure
> for longer ints as microprocessors move to 64 bit words.

Especially since the size of a "word" on a PowerPC is 32 bits, and a
"longword" is 64 bits...so when we say "short" in C, we get a
half-word, and a "char" is a quarter-word. Potential confusion
galore....

-kevin

//---------------------------------------------------------------------
   Kevin Tieskoetter / Software Prestidigitator, Specular International
//---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From Mark Williams <[e-mail]>
Date: Thu, 16 Nov 95 08:56:23 GMT
Organization: Streetly Software


In article <[e-mail]>, Jim Jarrett writes:

>
> In article
> <[e-mail]>,
> Shyguy <[e-mail]> wrote:
>
> >
> > Yet I have never seen any other book say not to use ints!
> > Why the big fuss about using shorts or longs?  You can just tell the
> > compiler to treat ints as 2 bytes or 4 bytes anyways
>
> And this is EXACTLY why not to use ints. C does not put any definition on
> what sizeof(int) should be.  If you try to port code across platforms (or
> even across projects), you can have things break in all kinds of
> fun-to-debug ways because compiler A had ints as 2 bytes and compiler B
> has ints as 4 bytes.
>
> short and long ARE defined, however.

No, they are not. There are C compilers for some processors where sizeof(long)=sizeof(char)=1.

But that asside, the whole point of int is that its supposed to be the most efficient sized integer
type at the machine level.

so eg

struct {
        char a[6];
 } array[1000];

int x;
for (x=0;x<1000;x++)
        do_something_to(&array[x]);

On 68000 you would hope to have 2 byte ints, so that the multiply is done in hardware, on 68020 and
later you dont really care, and on PPC you want 4 byte ints, so that you dont have to keep sign
extending x. [I know a decent optimising compiler should be able to cope with _this_ example, but
for more complex cases it wouldnt help]

Specifying either short or long, you would get ineficient code on one or other of the platforms.

The only time you want to avoid using ints is in "shared data" situations - eg if your app supports
plugins, you need to keep ints out of the interface. If you read and write binary data to files, you
need to avoid using ints.

But I would also recommend avoiding the use of short and long in those situations. Apple has
introduced SInt16 , SInt32 etc types in the headers. Use them. Because we could be seeing 64 bit
longs quite soon - to take advantage of the 620.

- --------------------------------------
Mark Williams<[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (David Nebinger)
Date: 18 Nov 1995 17:26:16 GMT
Organization: epix.net

Shyguy ([e-mail]) wrote:
: Yet I have never seen any other book say not to use ints!
: Why the big fuss about using shorts or longs?  You can just tell the
: compiler to treat ints as 2 bytes or 4 bytes anyways

Just because you can change the compiler's interpretation of an integer
doesn't mean you can change the toolbox's interpretation of an integer.

By specifying (by short of long) the type of integer you are using, you
will know that regardless of what the compiler is doing with ints the
correctly sized value will be given to the toolbox.

That is why it is important to avoid ints in Mac code; portability, etc.,
but they are minor compared to the values required by the toolbox.

Dave Nebinger
[e-mail]


+++++++++++++++++++++++++++

>From Mark Williams <[e-mail]>
Date: Sun, 19 Nov 95 08:33:28 GMT
Organization: Streetly Software


In article <48l4vo$[e-mail]>, David Nebinger writes:

>
> Shyguy ([e-mail]) wrote:
> : Yet I have never seen any other book say not to use ints!
> : Why the big fuss about using shorts or longs?  You can just tell the
> : compiler to treat ints as 2 bytes or 4 bytes anyways
>
> Just because you can change the compiler's interpretation of an integer
> doesn't mean you can change the toolbox's interpretation of an integer.
>
> By specifying (by short of long) the type of integer you are using, you
> will know that regardless of what the compiler is doing with ints the
> correctly sized value will be given to the toolbox.
>
> That is why it is important to avoid ints in Mac code; portability, etc.,
> but they are minor compared to the values required by the toolbox.

This is not a problem. If you pass an int by value, it will be converted for you. If you try to pass
a pointer to an int to a toolbox routine, it will spit it out.

- --------------------------------------
Mark Williams<[e-mail]>

---------------------------

>From [e-mail] (Alex L. Bangs)
Subject: Drag and Drop ShowDragHilite problem
Date: Thu, 16 Nov 1995 19:35:49 GMT
Organization: Earth2, New Pacifica Station

I have a Drag & Drop problem where I the highlighting doesn't appear
correctly when I used a non-white background in my window. If my
background is lighter than RGB values of 62000, then it works fine. If the
background is darker than that -- say 61500, then the drop points don't
highlight when I drag over them. If I change it to *outside* hiliting
(ShowDragHilite with inside=false), then the highlighting shows. The
window hiliting, which is effectively inside the window, works regardless
(i.e. when I drag outside of a drop area, then the window highlights
properly to show it will accept the drop, regardless of how dark the
background is).

I would prefer to use inside hiliting since this seems to be more standard
and looks better for most of my objects.

The drop areas have a different background color (white), but this doesn't
appear to be the cause of the problem.

Any ideas?

Thanks,
Alex

--
Alex L. Bangs
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jeremy Roschelle)
Date: 17 Nov 1995 19:04:40 GMT
Organization: SimCalc

In article <[e-mail]>,
[e-mail] (Alex L. Bangs) wrote:

>I have a Drag & Drop problem where I the highlighting doesn't appear
>correctly when I used a non-white background in my window. If my
>background is lighter than RGB values of 62000, then it works fine. If the

Before calling ShowDragHilite, call:

::RGBBackColor(&yourColor);

HIlite mode reverses pixels that are the same color as the background
color set in the port.

Besure to restore the color after your done.

jeremy

jeremy              > > > > > > > > > > * Jeremy Roschelle
                                        * SimCalc Project
                                        * 4104 24th Street #344
                                        * San Francisco CA 94114
                                        * 415 695.2801

---------------------------

>From Rusty Little <[e-mail]>
Subject: Picture's Bounding Region?
Date: 21 Nov 1995 17:01:02 GMT
Organization: Houston, Texas

Hi,

I've got a picture that is not rectangular. I would like to know what's
it's bounding region is on the fly. I haven't found any region info
within the PicHandle. Does anyone know how you can get the bounding
region of a non-rectanglular picture on the fly?

If you know, thanks in advance for your help!!! Responses via e-mail are
best for me.

Thanks again,

Rusty Little
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Tim Dierks)
Date: Tue, 21 Nov 1995 23:24:00 -0800
Organization: Best Internet Communications

In article <48t0ke$[e-mail]>, Rusty Little
<[e-mail]> wrote:
>I've got a picture that is not rectangular. I would like to know what's
>it's bounding region is on the fly. I haven't found any region info
>within the PicHandle. Does anyone know how you can get the bounding
>region of a non-rectanglular picture on the fly?

If you do an OpenRgn(), a DrawPicture(), then a CloseRgn() you'll get the
same effect as if you executed all of the operations in the picture
individually. Unfortunately, that probably won't be what you want-
overlapping primitives will have empty spots where they overlap. Instead,
you should probably replace all the relevant bottleneck procedures in your
GrafPort with versions which accumulate each boundary into a cumulative
region. To do this:

 - Create two new regions, totalRgn and opcodeRgn. The variables should be
globals.
 - Draw the picture
 - Inside of each bottleneck proc:
   - SetEmptyRgn(opcodeRgn);
   - OpenRgn();
   - call the underlying procedure (for example, in the rectProc, you'd
call StdRect). Change the verb to 'frame'.
   - CloseRgn(opcodeRgn);
   - UnionRgn(opcodeRgn,totalRgn,totalRgn);

Now you'll have the union of all the objects in the region. You'll need to
call the StdRect primitive for bitmaps. Text will be non-trivial to do
right. You'll need to do special work for arcs. To do lines correctly,
construct a region which describes the exterior of a line with the pen
size in question (it'll be a hexagon for all diagonal lines, a rectangle
for horizontal or vertical lines).

Golly, this is harder to do than I thought it'd be when I started. Another
option, which might be easier, is to image the PICT into an offscreen
bitmap. Modify the bottlenecks to always paint in black. Then call
BitMapToRegion() to collect the resulting outline. Benefits are that it
works with all the opcodes and works correctly with text, etc. You'll have
to modify the bitsProc to call StdRect, again, unless you want to try to
create a mask for the bitmaps in the PICT. (I've got some ideas on that,
too, but I won't go into them here.)

 - Tim

--
Tim Dierks - Software Haruspex - [e-mail]
If you can't lick 'em, stick 'em on with a big piece of tape. - Negativland

---------------------------

>From [e-mail] (Gregory Jackson)
Subject: Plugins?  How?
Date: Mon, 13 Nov 1995 05:42:40 -0600
Organization: UAB

I am interested in using the power of plugins like Eudora to extend the
functioning of a program that I am writing.  If my associates use the
program, I may have to change some of the code to support their setup.  Is
there an IM or examples on the Net of how to do this?

Thank you much,

Greg

+++++++++++++++++++++++++++

>From [e-mail] (Martin-Gilles Lavoie)
Date: Tue, 14 Nov 1995 19:59:39 -0500
Organization: ZERCOM Technologies Inc.

In article <[e-mail]>,
[e-mail] (Gregory Jackson) wrote:

> I am interested in using the power of plugins like Eudora to extend the
> functioning of a program that I am writing.  If my associates use the
> program, I may have to change some of the code to support their setup.  Is
> there an IM or examples on the Net of how to do this?
>
> Thank you much,
>
> Greg

Checking out the "HyperXCmd.h" header file from any respectable compiler's
Universal Headers include folder may be a good place to start.

To my knowlege, HyperCard is the most "plugged-in" app around (next to
MacOS).  And many applications are actually using HyperCard extensions
directly.

(Annecdote; HyperCard is the "brain" behind Montreal-based National Film
Board of Canada's video library, where each viewing booths are equipped
with viewing screens and (touch-screen) Macs for complete listing of
movies produced by NFB (1000+), which sends requests to a Mac-controled
robotic arm wich loads in your requested video disk in a player assigned
to your viewing booth.  The whole works is HyperCard, and a few HyperCard
XFNCs and XCMDs.  It's actually quite hi-tech to see this.)

>From my own experience with plug-ins though, try not givving your
extensions developpers direct access to your structures.  Either use
special routines to access data (accessors), or use alternate structures.
This makes it simpler to update your code without breaking the extensions,
and also tends to keep the extensions developper include files smaller
(though it works, the Quark XPress extensions files are *HUGE* and ratter
impractical).

I have an application with uses custom plug-ins.  Messages are being
passed to extensions using two OSTypes, one for the event class, the other
for the actual event.  I use the same constants as those used in
AppleEvents.  It works ratter nicelly, and makes one thing less to
remember.

Martin-Gilles Lavoie
- -------------------------------------------------------------------
No!...try not.  Do, or do not.  There is no try.
    --Yoda on error handling.

Wars does not make one great.
    --Yoda on "Great Warrior"

+++++++++++++++++++++++++++

>From [e-mail] (Patrik Johansson)
Date: Wed, 15 Nov 1995 19:45:19 +0100
Organization: KTH

> I have an application with uses custom plug-ins.  Messages are being
> passed to extensions using two OSTypes, one for the event class, the other
> for the actual event.  I use the same constants as those used in
> AppleEvents.  It works ratter nicelly, and makes one thing less to
> remember.

Just curios, can you tell us more about how you communicate with your
plug-ins? Do you have real two way communication or do you just send data
to it from the main application? How are your plug-ins stored? As CODE
resources? How do you load them so you can communicate with it?

Pj

+++++++++++++++++++++++++++

>From [e-mail] (J.W. Luiten)
Date: 16 Nov 1995 08:20:56 GMT
Organization: ID Systems/TI

In article <[e-mail]>,
[e-mail] (Gregory Jackson) wrote:

> I am interested in using the power of plugins like Eudora to extend the
> functioning of a program that I am writing.  If my associates use the
> program, I may have to change some of the code to support their setup.  Is
> there an IM or examples on the Net of how to do this?
>
> Thank you much,
>
> Greg

Have a look at the Code Fragment Manager. All functionality needed is in there.
MacTech (www.mactech.com) has an excellent example of how to use it. The
example is in volume 10 and is called "Powering Up".


Kind regards,

J.W. Luiten.

+++++++++++++++++++++++++++

>From [e-mail] (Avi Rappoport)
Date: Fri, 17 Nov 1995 10:55:39 -0800
Organization: Metrowerks Corporation

In article <[e-mail]>,
[e-mail] (Gregory Jackson) wrote:

) I am interested in using the power of plugins like Eudora to extend the
) functioning of a program that I am writing.  If my associates use the
) program, I may have to change some of the code to support their setup.  Is
) there an IM or examples on the Net of how to do this?
)
The new book "A Fragment of Your Imagination" by Joe Zobkiw, covers
componants and code resources as well as code fragments.  It's got
examples of Photoshop filters and such.  From Addison-Wesley, ISBN
0-201-48358-0.

--
Avi Rappoport                                  [e-mail]
User Advocate and Publications Coordinator
Metrowerks Corporation

---------------------------

>From [e-mail] (Kevin Stone)
Subject: Programing For Joysticks?
Date: 16 Nov 1995 21:21:32 GMT
Organization: South Dakota School of Mines and Technology
   Can anyone tell me where I can get all the nessesary information to
program for all the popular joysticks and game-pads.  I suppose could just
write to the companies that make them... but I don't know where I can get
their e-mail addresses.
   Any info would be helpful. :)

Thanks.
Sincerly,
  Brian Stone
  [e-mail]
  Respond To: [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (TheBug)
Date: Sun, 19 Nov 1995 18:10:42 +0100
Organization: privat

In article <48ga0s$[e-mail]>, [e-mail] (Kevin
Stone) wrote:

>    Can anyone tell me where I can get all the nessesary information to
> program for all the popular joysticks and game-pads.  I suppose could just
> write to the companies that make them... but I don't know where I can get
> their e-mail addresses.
>    Any info would be helpful. :)

If you need info for the CH Products stuff, contact me. CH and Fesh! have
recently released an API that allows you to use game controllers without
specifically programming for any of them. JoyManager delivers information
about the capabilities of the available devices.

--
*******************************************************************
Guido Körber -            Programmer and hardware hacker
[e-mail]    Specialised in mistreating the ADB
fax: x49-30-773 81 36     Ask me about:
                           Flightstick Pro, Jetstick
                           MacEnjoy, MacEnjoy Style

Opinions expressed herein are mine unless expressly stated
otherwise. Similarities with living or undead persons are
coincidence and not intended - really!   ;-)
Best use before: (see date printed on backside of message)
*******************************************************************

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Barry)
Date: Tue, 21 Nov 1995 22:39:30 +1000
Organization: OzEmail Pty Ltd - Australia

In article <48ga0s$[e-mail]>, [e-mail] (Kevin
Stone) wrote:

>    Can anyone tell me where I can get all the nessesary information to
> program for all the popular joysticks and game-pads.  I suppose could just
> write to the companies that make them... but I don't know where I can get
> their e-mail addresses.
>    Any info would be helpful. :)

You can contact Guido Koerber of Fesh! who is distributing a joystick API
for joysticks that are made by Fesh! and CH.

The address I have is:
[e-mail]

The key phrase is "JoyManager SDK".

I hope this helps.

Andrew Barry

+++++++++++++++++++++++++++

>From [e-mail] (TheBug)
Date: Tue, 21 Nov 1995 17:22:44 +0100
Organization: privat

In article <[e-mail]>,
[e-mail] (Andrew Barry) wrote:

> You can contact Guido Koerber of Fesh! who is distributing a joystick API
> for joysticks that are made by Fesh! and CH.
>
> The address I have is:
> [e-mail]

Actually I prefer if you address me at: [e-mail]
I will send SDKs to all interested people (about 400k though...).

We have just opened a ListServ to discuss the future directions of
JoyManager, contact me if you are interested.

--
*******************************************************************
Guido Körber -            Programmer and hardware hacker
[e-mail]    Specialised in mistreating the ADB
fax: x49-30-773 81 36     Ask me about:
                           Flightstick Pro, Jetstick
                           MacEnjoy, MacEnjoy Style

Opinions expressed herein are mine unless expressly stated
otherwise. Similarities with living or undead persons are
coincidence and not intended - really!   ;-)
Best use before: (see date printed on backside of message)
*******************************************************************

---------------------------

>From [e-mail] (Kevin Hayes)
Subject: Registering File Creators and Types
Date: Thu, 16 Nov 95 16:01:10 GMT
Organization: Dalhousie University

Hi all,

If this is in an FAQ, please post a location. I'm trying to register a file
type and creator code for my new shareware game. Does anyone know how I should
go about doing this? I've checked Apple's Web sites but couldn't find any
info. (They're in the middle of reorganizing everything, it's hard to get
around these days)

Thanks,
Kevin.


+++++++++++++++++++++++++++

>From [e-mail] (Ed Anson)
Date: Fri, 17 Nov 1995 00:40:35 -0500
Organization: Tulip Software

In article <[e-mail]>, [e-mail] (Kevin
Hayes) wrote:

> Hi all,
>
> If this is in an FAQ, please post a location. I'm trying to register a file
> type and creator code for my new shareware game. Does anyone know how I
should
> go about doing this? I've checked Apple's Web sites but couldn't find any
> info. (They're in the middle of reorganizing everything, it's hard to get
> around these days)

Apple recently announced a new web page that includes a registration form
as well as a database of codes that are in use. I just visited it earlier
today, and it is a great step in the right direction.

I can't remember the URL, and it's on the Mac at my other office. If you
still can't find it, just send me e-mail at <mailto:[e-mail]>
and I'll look it up for you.

- --------------------
Ed Anson
Tulip Software
Andover, MA 01810   Check out my WWW page:
U.S.A.              <http://www.tiac.net/users/tulip/home.html>

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Thu, 16 Nov 1995 22:37:31 -0800
Organization: Townsend Communications

In article <[e-mail]>, [e-mail] (Kevin
Hayes) wrote:

> Hi all,
>
> If this is in an FAQ, please post a location. I'm trying to register a file
> type and creator code for my new shareware game. Does anyone know how I
should
> go about doing this? I've checked Apple's Web sites but couldn't find any
> info. (They're in the middle of reorganizing everything, it's hard to get
> around these days)

It is an FAQ (I don't know where the answer is), but the answer has
changed within the last few days.

On Apple's Web servers (somewhere) is a form you can fill out using a
browser to do your registration.  The old ways still work (paper form to
Apple, suitable email to Apple).

   --John

--
  "This item is not available because it cannot be removed."
John W. Baxter    Port Ludlow, WA     [e-mail]

+++++++++++++++++++++++++++

>From Dave Overton <[e-mail]>
Date: Fri, 17 Nov 1995 14:17:40 GMT
Organization: DataStream Imaging Systems, Inc.

Kevin,
Oddly enough, Apple DTS just sent this around.
Dave Overton



Item    3960360                         9-Nov-95        16:31PST

From:   DEV.NEWS                        News for Apple Developers,ESI

To:     PAS19$                          Apple Associates
        PAS20$                          Apple Associates

- ---------------------------------------------------------------------
- ----

Sub:    WWW Reg of Creator/File Types

Dear Developers,

Apple has recently made changes to improve and simplify the process of
registering creator and file type codes with Apple.  We have placed the
registration system on the World Wide Web, and we have also published a
database
of creator/file types already assigned to developers.  Both of these
changes
have been in response to developer requests.

The new creator/file type registration system is now available at the
following
URL:http://dev.info.apple.com/cftype/main.html.  We will continue to use
the
old HyperCard stack because all developers do not have access to the Web.
We
encourage those developers who do have access to the web to register their
application information using the above URL. On this web site you can do
the
following:
    - Register creator and/or file type codes with Apple
    - Search the Apple creator code database
    - Get answers to common questions regarding registration

We've also created a searchable database on the World Wide Web.
Developers can
search up to 16 codes at a time to see if they have been assigned by
Apple.
Owner Information related to the codes, such as company, contact, address,
phone, etc., cannot be published because that developer information is
confidential.

Your feedback is important to us! If you have any questions or comments
please
send them to Apple Developer Support at the electronic email address
"[e-mail]".  Below you'll find a Q&A that may
answer
some of your questions.

Sincerely,

Apple Developer Support

=============================================================
Q&A Section
=============================================================
Q: How does the WWW creator/file type registration page improve the
registration process for developers?
A:  The on-line registration system improves the registration process in
several ways.
    - an up-to-date searchable database
    - convenient registration for developers with Web access
    - faster turn-around time in processing registration requests
    - better data validation (registrations not accepted until data
entered
correctly)
    - ability to search the database for creator codes (application
signatures)
    - on-line documentation to assist with common registration questions
    - immediate feedback (if a code is taken, you'll find out online)
    - no need to have HyperCard installed
    - accessible via any forms-capable browser (NetScape, Mosaic, MacWeb,
eWorld, AOL, etc.)

Q: Why do I need to register the creator or file type for my application?
A: Registering your application creator code with Apple ensures that it is
unique. The Macintosh OS requires unique creator codes so that it can
correctly
identify applications and documents.

Q: Creator codes need to be registered with Apple to ensure that they are
unique, but why do file types need to be registered with Apple if they do
not
need to be unique?
A: You only need to register your creator codes with Apple. File type
registrations are optional, and Apple may discontinue registering them in
the
future.

Q: Are there any creator or file type codes developers can't use?
A: Creator codes and files types consisting entirely of all lower case
characters (a-z) are reserved for use by Apple.

Q: Where can a developer get more information on creator and file types?
A: Please see Inside Macintosh:Macintosh Toolbox Essentials, chapter 7,
"The
Finder Interface" (ISBN 0-201-63243-8). Macintosh Technical Note #36 also
is
helpful. And of course, we are available to help answer questions at
Apple's
Developer Support Center (electronic mail:
[e-mail]).

Q: When should I register my creator/file type codes with Apple?
A: You should register your codes with Apple as early as possible. Many
developers wait until the application is done and ready to go to
manufacturing
only to find out the code they have selected is in use.

Q: Do icons, fonts, or resource types need to be registered with Apple?
A: No. Apple no longer registers either icons, fonts, or resource types.

Q: What do I do if the creator code I am requesting has already been
assigned?
A: You will need to request an alternate code. By using the Web
registration
form, you will find out immediately if the code you are requesting has
already
been assigned.

Q: How will I know my registration has been processed after I have
submitted it
using the registration form on the Web?
A: After your registration is submitted using the Web registration form a
confirmation will be sent out via electronic mail within 2-3 business
days. If
you do not receive a confirmation within 2-3 business days, you should
send an
electronic mail message to [e-mail] requesting the
status
of your registration. In the mail message, please include the following
information about yourself:
    Name:
    Company:
    Mail Address:
    Phone Number:
    Date you submitted your registration:

Please note that most registrations are processed within 48 hours.  It is
very
important that you supply a postal mail address and phone number when
submitting any question to [e-mail]. If an
electronic
mail message is sent to the address indicated by you, and the address is
incorrect or undeliverable, we do not have any alternate way to contact
you.

Q: Must a developer be a member of Apple's Developer programs to register
their
creator or file type information?
A: You do not need to be a member of Apple's Developer programs to use
this
service.

Q: Can I get a list of all the codes maintained by Apple?
A: The only information Apple can give out from the creator/file type
database
is the list of creator codes. These codes are now available and
searchable on
Apple's creator/file type registration page on the Web. The URL of the
search
form is:
http://dev.info.apple.com/cftype/find.html
We cannot give out any other information in the database. Information
such as
company name, contact, address, and phone number is confidential.

Q: Why can't I use the Creator/File type registration stack that is
distributed
by Apple?
A: You can continue to use the registration stack that Apple distributes
via
CD, the internet, and on-line services.  Your registration will be
processed
more efficiently if you use the Web registration form. If you do not have
access to Apple's Web registration form then you should use the HyperCard
registration stack. Please note the HyperCard registration stack contains
an
internal database of creator codes that have already been assigned by
Apple.
The creator codes contained in the HyperCard stack are at least 1-2
months old.
When using the stack to register a new code, a check is made against the
internal database, but the database in the stack is at least 1-2 months
old. If
you are using an older version of the stack (which is very common), then
the
internal database of assigned codes is even older.

Q: The current HyperCard registration stack says I should send my
registration
to "[e-mail]", but I've been told the correct address is
"[e-mail]".
A: You can send the registration to either  "[e-mail]" or
"[e-mail]". Normal developer questions should still
be
sent to "[e-mail]".

+++++++++++++++++++++++++++

>From [e-mail] (Ed Anson)
Date: Fri, 17 Nov 1995 20:50:40 -0500
Organization: Tulip Software

In article <[e-mail]>, [e-mail] (that's
me) wrote:

> Apple recently announced a new web page that includes a registration form
> as well as a database of codes that are in use. I just visited it earlier
> today, and it is a great step in the right direction.
>
> I can't remember the URL, and it's on the Mac at my other office. If you
> still can't find it, just send me e-mail at <mailto:[e-mail]>
> and I'll look it up for you.

That was yesterday. Today, I found the URL again. Since there appears to
be some interest, I'll post it here:

   <http://dev.info.apple.com/cftype/main.html>

It sure beats the old method of using HyperCard stacks and AppleLink.

- --------------------
Ed Anson
Tulip Software
Andover, MA 01810   Check out my WWW page:
U.S.A.              <http://www.tiac.net/users/tulip/home.html>

+++++++++++++++++++++++++++

>From [e-mail] (Joel Klecker)
Date: Sun, 19 Nov 1995 11:43:45 -0800
Organization: The House of Beavis

In article <[e-mail]>, [e-mail] (Kevin
Hayes) wrote:

#If this is in an FAQ, please post a location. I'm trying to register a file
#type and creator code for my new shareware game. Does anyone know how I should
#go about doing this? I've checked Apple's Web sites but couldn't find any

<URL:http://dev.info.apple.com/cftype/main.html>

--
Joel Klecker
[e-mail]
http://www.teleport.com/~jklecker/
Netscape: The Microsoft of the Internet

+++++++++++++++++++++++++++

>From [e-mail] (Jeremy Roschelle)
Date: 19 Nov 1995 17:35:29 GMT
Organization: SimCalc

In article <[e-mail]>, [e-mail] (Kevin
Hayes) wrote:

>Hi all,
>
>If this is in an FAQ, please post a location. I'm trying to register a file
>type and creator code for my new shareware game. Does anyone know how I should
>go about doing this? I've checked Apple's Web sites but couldn't find any.

If you have a developer CD, there is a stack on it for registration. If
not send e-mail to

[e-mail]

jeremy

jeremy              > > > > > > > > > > * Jeremy Roschelle
                                        * SimCalc Project
                                        * 4104 24th Street #344
                                        * San Francisco CA 94114
                                        * 415 695.2801

+++++++++++++++++++++++++++

>From [e-mail] (Alain Roy)
Date: Mon, 20 Nov 1995 15:43:00 GMT
Organization: It lurks in the night

In article <[e-mail]>,
[e-mail] (Jeremy Roschelle) wrote:

>In article <[e-mail]>, [e-mail] (Kevin
>Hayes) wrote:
>
>>Hi all,
>>
>>If this is in an FAQ, please post a location. I'm trying to register a file
>>type and creator code for my new shareware game. Does anyone know how I
should
>>go about doing this? I've checked Apple's Web sites but couldn't find any.
>
>If you have a developer CD, there is a stack on it for registration. If
>not send e-mail to
>
>[e-mail]

I'd suggest checking out:

http://dev.info.apple.com/cftype/main.html

-alain

---------------------------

>From [e-mail] (Lars Farm)
Subject: ResourceHandle?
Date: Wed, 15 Nov 1995 11:15:14 +0100
Organization: pv

Is there a reliable and documented way to determine if a Handle refers to a
resource or not? HGetState works only for non purged handles. HomeResFile
seems to work on purged handles, but I can't find anything in IM to support
this observation. Any other safe and documented way?


--
Lars Farm, [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Roger D. Placer)
Date: Thu, 16 Nov 1995 09:11:50 -0500
Organization: Virtuoso Software Consulting

In article <[e-mail]>, [e-mail]
(Lars Farm) wrote:

* Is there a reliable and documented way to determine if a Handle refers to a
* resource or not? HGetState works only for non purged handles. HomeResFile
* seems to work on purged handles, but I can't find anything in IM to support
* this observation. Any other safe and documented way?

Here's an easy way:

Boolean IsResHandle(Handle myHndl)
   {
   return (HomeResFile(myHndl) != -1);
   }


Roger

================================|=====================================
Sr. SW Engineer, BestWare Inc.     Pres., Virtuoso Software Consulting
  Rockaway, NJ                                           Oakland, NJ
    [e-mail]              [e-mail]
==== Makers of M.Y.O.B. ========|==== Custom Macintosh Solutions =====

+++++++++++++++++++++++++++

>From [e-mail] (Marshall Clow)
Date: Sat, 18 Nov 1995 20:31:00 -0800
Organization: Aladdin Systems

In article <[e-mail]>, [e-mail]
(Lars Farm) wrote:

>Is there a reliable and documented way to determine if a Handle refers to a
>resource or not? HGetState works only for non purged handles. HomeResFile
>seems to work on purged handles, but I can't find anything in IM to support
>this observation. Any other safe and documented way?
>
Congratulations on a good description of the problem.

Here's my answer:
   Use HomeResFile. The documentation for HRF says nothing about whether
or not the handle is purged, while the docs for HGetState specifically
state that HGetState does not work for purged handles.

Consider the following code fragment:

   SetResLoad ( false );
   h = GetResource ( 'xxxx', yyy );
   SetResLoad ( true );
   if ( h == nil )  // Get a good error, because the Resource mgr lies!
      err = ResError () != noErr ? ResError () : resNotFound;
   else {
      fRefNum = HomeResFile ( h );
      if ( fRefNum == 2 ) { // System file
         LoadResource ( h );
         if (( err == ResError ()) == noErr ) {
            .....
            }
         }
      }

and so on.

Calling GetResource with ResLoad set to false is perfectly legal.
It's a valid resource handle. (empty, but valid) You can call
LoadResource, DetachResource, HomeResFile, ReleaseResource, etc on it.

-- Marshall

--
Marshall Clow
Aladdin Systems

"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety." -- Benjamin Franklin
 _Historical Review of Pennsylvania_, 1759

---------------------------

>From [e-mail] (Steve Scipioni)
Subject: Text is text is text...isn't it?
Date: Mon, 20 Nov 1995 12:31:09 -0400
Organization: NAI

What is the difference between UNIX, DOS, and Mac text format?  I thought
that ASCII was ASCII.  I'm writing this is BBEdit, and will save it as Mac
format, which is how I have the program set up as default.  I'll then open
it in Newswatcher, and send it off to this newsgroup. I also use BBEdit to
write HTML documents, and my HTML seems to load just fine once it's on the
server (a UNIX system).

I have come to understand that the primary difference between the way the
three OS's handle text is by way of "end of line conventions."  Just how
does a line feed differ from a carriage return?  And is it true that the
Mac uses both?  How is text rendered on other systems when it encounters a
file that was created on a different system that uses a convention
different from its own?

TIA,

Steve

+++++++++++++++++++++++++++

>From [e-mail] (R Shapiro)
Date: Mon, 20 Nov 1995 13:55:10 -0500
Organization: BBN

In article <[e-mail]>, [e-mail]
(Steve Scipioni) wrote:

>What is the difference between UNIX, DOS, and Mac text format?

Different logical end-of-line marks. Unix uses linefeed (ascii 10), Mac
uses carriage return (ascii 13), Dos use cr+lf. Line-oriented programs on
the various platforms typically depend on finding the right mark. Eudora,
for instance, will not understand message-header and message-separator
lines if they're terminated ala Unix or Dos.

--
rs/[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Marshall Clow)
Date: Mon, 20 Nov 1995 15:26:58 -0800
Organization: Aladdin Systems

In article <[e-mail]>, [e-mail]
(Steve Scipioni) wrote:

>What is the difference between UNIX, DOS, and Mac text format?  I thought
>that ASCII was ASCII.  I'm writing this is BBEdit, and will save it as Mac
>format, which is how I have the program set up as default.  I'll then open
>it in Newswatcher, and send it off to this newsgroup. I also use BBEdit to
>write HTML documents, and my HTML seems to load just fine once it's on the
>server (a UNIX system).
>
>I have come to understand that the primary difference between the way the
>three OS's handle text is by way of "end of line conventions."  Just how
>does a line feed differ from a carriage return?  And is it true that the
>Mac uses both?  How is text rendered on other systems when it encounters a
>file that was created on a different system that uses a convention
>different from its own?
>

You are correct.
The difference between text files on Mac, Unix and Dos are all in the
end-of-line characters.

Unix uses the line-feed character   (character 10) to mark the end of line.
The Mac uses the carriage-return character (character 13)
DOS uses a line-feed followed by a carriage return!

-- Marshall

--
Marshall Clow
Aladdin Systems

"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety." -- Benjamin Franklin
 _Historical Review of Pennsylvania_, 1759

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 21 Nov 1995 13:20:42 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Steve Scipioni <[e-mail]> wrote:

>I have come to understand that the primary difference between the way the
>three OS's handle text is by way of "end of line conventions."

This is correct. However, another important difference for non-English
speaking users is in the coding convention for accented letters.

Dos uses an old IBM convention, Unix and Windows usually use the
ISO-Latin-1 standard (which doesn't have a code for the French oe,
damnit) and Apple has its own convention.

Apple also screwed it up by making its Japanese two-byte character set
incompatible with its usual 8-bit character set, i.e. you can't have
French accents on a Mac Japanese system.




--
Francois
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: 21 Nov 1995 16:37:05 GMT
Organization: National Renewable Energy Laboratory

In article <[e-mail]> Marshall Clow,
[e-mail] writes:

>You are correct.
>The difference between text files on Mac, Unix and Dos are all in the
>end-of-line characters.

Another minor difference is end-of-file handling.  MS-DOS text files end
at the first control-Z character, regardless of any other data in the
file after the cntl-Z.  Macintosh files just use the file length
recorded in the disk directory.

+++++++++++++++++++++++++++

>From [e-mail] (Johan Almqvist)
Date: Wed, 22 Nov 1995 16:47:54 +0200
Organization: none

In article <[e-mail]>,
[e-mail] (Marshall Clow) wrote:

> In article <[e-mail]>, [e-mail]
> (Steve Scipioni) wrote:
>
> >What is the difference between UNIX, DOS, and Mac text format?  I thought
> >that ASCII was ASCII.  I'm writing this is BBEdit, and will save it as Mac
> >format, which is how I have the program set up as default.  I'll then open
> >it in Newswatcher, and send it off to this newsgroup. I also use BBEdit to
> >write HTML documents, and my HTML seems to load just fine once it's on the
> >server (a UNIX system).
> >
> >I have come to understand that the primary difference between the way the
> >three OS's handle text is by way of "end of line conventions."  Just how
> >does a line feed differ from a carriage return?  And is it true that the
> >Mac uses both?  How is text rendered on other systems when it encounters a
> >file that was created on a different system that uses a convention
> >different from its own?
> >
>
> You are correct.
> The difference between text files on Mac, Unix and Dos are all in the
> end-of-line characters.
>
> Unix uses the line-feed character   (character 10) to mark the end of line.
> The Mac uses the carriage-return character (character 13)
> DOS uses a line-feed followed by a carriage return!

There's some more to it: We Europeans have strange Chars whose 8bit codes differ
from system to system (such as äüößÖÄÜ ë  éèê  Å and so on (if this is
transferred correctly?!?!?)

> -- Marshall
>
> --
> Marshall Clow
> Aladdin Systems
>
> "They that can give up essential liberty to obtain a little temporary
>  safety deserve neither liberty nor safety." -- Benjamin Franklin
>  _Historical Review of Pennsylvania_, 1759

--
--
(URL: <http://www.hamburg.netsurf.de/~johan.almqvist>)
(URL: <mailto:[e-mail]>)

+++++++++++++++++++++++++++

>From [e-mail] (Richard Wells )
Date: 22 Nov 1995 17:54:21 GMT
Organization: 3M Company

Carl R. Osterwald <[e-mail]> wrote:
>In article <[e-mail]> Marshall Clow,
>[e-mail] writes:
>
>>You are correct.
>>The difference between text files on Mac, Unix and Dos are all in the
>>end-of-line characters.
>
>Another minor difference is end-of-file handling.  MS-DOS text files end
>at the first control-Z character, regardless of any other data in the
>file after the cntl-Z.  Macintosh files just use the file length
>recorded in the disk directory.

Actually, this is no longer true.  No DOS or Windows program worth
its salt depends on finding a ctrl-z character to mark EOF.  Of
course, the number of DOS/Windows worth their salt is an open
question in this group (:-).

In fact, the only program I can think of that uses ctrl-z to mark
the end of file is COMMAND.COM, whose COPY command will stop upon
finding a ctrl-z in the input (unless you specify /b).  Just one
more charming DOS idiotsyncracy.

I think the original reason for using ctrl-z was compatibility with
CP/M, which only kept track of the number of 128-byte blocks allocated
to a file, but not the actual file length.



+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 22 Nov 1995 18:52:04 -0800
Organization: Townsend Communications

In article <[e-mail]>, [e-mail]
(Steve Scipioni) wrote:

> What is the difference between UNIX, DOS, and Mac text format?  I thought
> that ASCII was ASCII.

ASCII is ASCII, and only defines the character values from 0x00 throu
0x7F.  End-of-line is a separate issue...all ASCII defines is the
characters, including CR as 0x0D, LF as 0x0A, record, field, group, and
??? separators (the RS, GS, FS, ?S) characters in the general area of 0x1C
or so (left over from punched paper tape, where a "line" was one row
across the tape, ie one character usually).

Line ends aren't part of ASCII.  Neither are the characters from 0x80
through 0xFF.

   --John

--
  "This item is not available because it cannot be removed."
John W. Baxter    Port Ludlow, WA     [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Dylan the Hippy Wabbit)
Date: 27 Nov 1995 12:51:53 GMT
Organization: Imperial Cancer Research Fund

 In article <[e-mail]>, [e-mail]
(Steve Scipioni) wrote:

> > What is the difference between UNIX, DOS, and Mac text format?  I thought
> > that ASCII was ASCII.

Macs reading PC clone text puts a  black box at every LF character,
Windows with Mac text tries to put it all on one line.  Why doesn't PC
Exchange deal with translation of a text file automatically?

Of course Mac, Dos/Windows, and Un*x ( who owns that this week?) aren't
all the systems in the world.  I gather many IBM mainframes use EDBIC,
which bears no resemblance to ASCII whatsoever.

Dave Spacey

--
Don't underestimate the abacus......it requires no power, can be made with any materials you have to hand, and never goes bing in the middle of an important piece of work.   (Many thanks to Douglas Adams.)

+++++++++++++++++++++++++++

>From [e-mail] (Robert Coie)
Date: Wed, 29 Nov 1995 13:02:47 -0800
Organization: Intrigue Corporation

In article <48sjna$[e-mail]>, [e-mail] (Francois
Pottier) wrote:

: Apple also screwed it up by making its Japanese two-byte character set
: incompatible with its usual 8-bit character set, i.e. you can't have
: French accents on a Mac Japanese system.

Agreed, you run into trouble with Japanese fonts, but the Japanese system
has all the Roman fonts of the U.S. system.  Does the French system have
extra fonts missing from U.S. English?  In any case, French accents have
worked perfectly well for me on every KanjiTalk version I have used (back
to 6.0) as long as I make sure to use Roman fonts.

I think you're being too hard on Apple:  I support the choice of Shift-JIS
for Japanese encoding because it allows context-free mixing of 7-bit ASCII
and Japanese and was largely compatible with the NEC 9800 series, which
had a huge share of the personal computer market in Japan when KanjiTalk
1.0 came out.  Using the >$80 characters for accents &c was also IMHO the
right decision when it was made.

The problem is that mixing text that uses the >$80 range in radically
different ways is not tenable unless extra information is stored, such as
a script code (as has been possible since Styled TextEdit and the Script
Manager made their debut).  Until all characters are at least two bytes
wide (as in Unicode), such conflicts are unavoidable, and the Mac OS does
the best job of minimizing the impact of these difficulties of any system
I have worked with.

Before DOS/V (2 or 3 years ago), you couldn't run English DOS on most
Japanese PCs, and lots of English software just wouldn't run.  With DOS/V
you have to restart to switch languages.  English Windows 3.1 won't run on
top of Japanese DOS and vice versa, and many English Windows apps won't
run under Japanese windows, so again you have to restart frequently to
switch languages.  Some Japanese characters are forbidden in DOS
filenames.  I don't know how Windows 95 handles these issues (the Japanese
version just shipped last week).  With Japanese X-Windows, the burden for
setting scripts lies largely on the user, and Unix Japanese character
encoding varies from vendor to vendor.  Moving documents from DEC Ultrix
to a Sun requires reencoding all Japanese text, for example.

On the MacOS,  one can switch from writing English to Japanese with one
keystroke, mix Japanese, English, and French in the same document and
never have to restart.  Although there are some exceptions and annoyances,
virtually all software written to run under the U.S. Mac OS at least works
under KanjiTalk and most programs even allow entry of Japanese even if the
programmer made no effort at all to support such.

Robert Coie
Implementor, Intrigue Corporation
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 30 Nov 1995 01:26:19 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Robert Coie <[e-mail]> wrote:

>I think you're being too hard on Apple:

Um, you're right, this solution was the best one since it allowed mixing
7 bit ASCII characters with Japanese. And French accents can be obtained
by explicitly selecting a Roman font. The only remaining problem is that
you can't have French accents in file names, because the Japanese Finder
uses a Japanese font for file names.

Thanks for setting things straight,

--
Francois
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (Bill Stewart-Cole)
Date: Tue, 21 Nov 1995 23:17:43 -0600
Organization: ZOG

In article <[e-mail]>, [e-mail]
(Steve Scipioni) wrote:

>What is the difference between UNIX, DOS, and Mac text format?  I thought
>that ASCII was ASCII.

ASCII is ASCII is a 7-bit encoding. Past 127 in an 8-bit byte, what you
get can vary, a lot. But that's not really what you are talking about.

>I'm writing this is BBEdit, and will save it as Mac
>format, which is how I have the program set up as default.  I'll then open
>it in Newswatcher, and send it off to this newsgroup. I also use BBEdit to
>write HTML documents, and my HTML seems to load just fine once it's on the
>server (a UNIX system).
>
>I have come to understand that the primary difference between the way the
>three OS's handle text is by way of "end of line conventions."  Just how
>does a line feed differ from a carriage return?  And is it true that the
>Mac uses both?  How is text rendered on other systems when it encounters a
>file that was created on a different system that uses a convention
>different from its own?

This is actually the real area of variation.

The Mac uses a carriage return (ASCII 13) to end lines. Actually, the more
common reality is that NOTHING ends lines on a Mac, because your text
usually wraps to a window. CR is more commonly a paragraph ending. This is
why with some plain text editors you get huge lines when opening a text
file made with SimpleText or many word processors.

DOS uses BOTH a carriage return then a line feed (ASCII 10) to break
lines. With Windows, this often really means paragraph breaks.

Unix systems actually vary a little. I believe some use LF+CR, some CR+LF,
some just CR. The most common is ( I THINK) LF+CR

The reason Unices (plural of Unix?) can vary is that there is a defined
standard for the "network virtual terminal" emulation used to do things
like telnet, and it is CR+LF. In addition, every other text-based Unix
session is done thru the tty devices, that get associated with whatever
other termional emulation is used. Hence, no matter what a file looks like
on disk, when you show it on your screen thru a terminal session, you get
whatever the terminal eulation says is the right line break.

The origin of this is the venerable teletype. On a teletype, a carriage
return is a distinct function from a line feed. Remember manual
typewriters? (No? am I getting OLD?)  The movement of the carriage back to
the start is not necessarily accompanied by a roll of the platen, and vice
versa. Teletypes are not, like video terminals, dependent on lines that
are filled to the left. Using CR and LF independently, things like
strikethru and doublestrike text and data-efficient
transmissions of things
                           like
                                    this
                                             were possible (without lots
of spaces sent at 75 baud) Hence the line break became 2 characters in
terminal-oriented operating systems.

--
Bill Stewart-Cole
What is Stewart-Cole Consulting?
Hell if I know. I'll find out when I finish the web page.
Current projected date: 12/1. I'm not saying what year

---------------------------

End of C.S.M.P. Digest
**********************